L' Effet Pommier 3/L'Effet Pommier - Volume 03.iso/Graphismes/3D/PatchDance 0.4.2b4/Read Me Later

Text File | 1995-07-27 | 8KB | 141 lines

PatchDance v0.4b4

Background information that may be interesting

Files:
 - PatchDance╒s native file format is designed for one purpose:  speed.
    Using a  number of techniques we have achieved one of the fastest
    save/load times in the  business.  The format is highly application-
    specific and there are no plans to  document it.
 - The (expected) downside is that files are relatively large.  A file
    containing  roughly 9,000 entities of each type (point, spline, patch) should
    fit on a 1.4 MB  floppy.  The files compress fairly well (we╒ve observed
    ~60% using Stuffit with small files.  This also writes to floppy faster
    than a direct Finder copy.)
 - The new file format (v0.4b2 and later) is even faster and also supports
    merging files and creating libraries.

Future Directions
Rendering:  This is under development.  Rendering per se is easy, fast ren
dering is much harder, and writing enough shaders to support a practical
rendering engine is  very time consuming.  We are currently looking into
the following areas:
1. Adopt an existing shader type.  We currently plan to use the new Quick
    Draw 3D specification.  This will allow importation of others╒ shaders;
    export of ours will be limited to features that QuickDraw 3D supports.
2. Network rendering is possible and intended (eventually).  Currently we
    plan to license commercial networking software rather than develop
    our  own system.  The cost is extremely high and will have to passed
    along to users who want the feature.

Animation:  This will begin to be added in v0.5.  It will be possible to
(automatically) save tweened frames individually for export.

Scheduled features:
 - Full support for particle effects.  This will be implemented first
    (soon) in the Modeler, where it is a useful tool as well.
 - Physical effects.  Motion/acceleration graphs for paths (with preset
    gravity, etc.) will be supported.  Our graph method allows the use of a
    fully editable spline graph (with presets for gravity, etc) anywhere a
    number can be used.
 - Collisions.  This allows triggering actions when a collision  is detected:
    i.e., when a vase hits the floor, the collision script divides it into
    pieces, activates particle effects, and causes the pieces  to tumble and
    fly apart.  And this will even be easy to set up!
 - Inverse Kinematics.  This will be the final end of a detailed set of
    motion constraints/object links.  No timetable.
 - EVERYTHING will be animatable.  This includes all shader parameters
    (even blending of shaders, whether or not it makes sense) and any
    modeling operations that make sense at all (even Lathe and Extrude.)

Modeling:  The modeler will continue to get better and faster.  The Trim
function is a high priority but also a great challenge and we want it to  be
perfect, even if we aren╒t the first to market with it.  (Though that still
looks likely at present.)

Scheduled additions:
 - Particle effects.  For modeling, this applies to operations where it
    makes sense.  It will initially be implemented as an option for the
    Scale  and Rotate tools.  The animation version will add many more
    possibilities  and controls.

-  Nonlinear effects.  Examples are Bend, Twist, Taper, Bulge, Ripple,  etc.
    The Magnet Tool is a first generation effort:  useful but still  rough.
    Nonlinears are fashionable and not hard to implement;  we╒ll be  happy
    to provide them if they╒re demanded.  We have a few questions:

    1) Which are the most useful/desired?  Use the program a little before
    voting, since some effects (Shear) ARE supported and others (Bend,
    Taper)  are not hard to fake with existing tools.  We╒re trying to
    avoid  redundancy or excessive numbers of specialized tools.

    2) What is a good interface?  These operations often have multiple
    variables, making them tricky to do interactively without arcane
    numeric  options.  We currently don╒t have a preferred method (conform
    object to  spline or ╥spine╙ techniques seem most feasible.)

 - MetaBalls.  This is difficult given the nature of the program, but  MB╒s
    have enthusiastic support here.  When and if implemented, they may
    take two forms:

    1) Traditional.  This would be a new type of primitive (like a point or
    spline.)  All MB parameters will be adjustable and animatable with
    out  limitation.  It will be possible (to some extent) to create a
    spline  mesh skin over a melted MB (no more export nightmares!)

    2) Blue Sky.  This highly speculative project involves applying the
    MetaBall effect to general objects (as a texture?)  Personally, I╒m
    not sure this behavior can defined well enough to be useful, and
    PatchDance  objects also don╒t remember their ╥original╙ shapes
    very well.  Don╒t hold  your breath on this one.


New Technology
Will be added as it makes sense.  Major issues:
- Multiple processors.  Based on preliminary data from Apple and DayStar,
    we expect good things from the new multiprocessor PowerMacs.  The
    time  frame for our implementation will depend on demand and the
    commercial success of the hardware.
 - OpenDoc.  PatchDance is unlikely to be suitable as an OpenDoc part (for
    3D editing within an OpenDoc document), due to the  nature of our
    multi-window interface.  We are excited about the  possibility of
    hijacking OpenDoc technology to provide high-quality image processing
    services from within PatchDance (experienced 3D users should be ex
    cited about that too), but this will not be available any time soon.
 - Copland (System 8).  This could have been designed just for us, and we
    expect it to significantly improve our performance and reliability (and
    make programming easier, as well).  It will be supported at the earliest
    possible moment.  If it works out well, PatchDance will quickly become
    a  System 8 only program.

Plugins.  (Programmers)
PatchDance is designed to allow the use of plugin extensions.  These  will
be in the form of PowerPC shared libraries, allowing easy access to  our
public API with minimal use of callbacks.  Our technology also avoids the
common problem of incredibly slow extension loading at startup.   Current
design allows for several types:  General operations (Model menu func
tions like Extrude);  Interactive (Tool Palette Tools -  it is  possible to
add new tools that are equivalent to ours, available from a  forthcoming
╥Generic╙ button on the palette);  Animation (later);  Shaders  (later); and
file import/export (long term, hopefully QD3D will suffice.)  The Develop
er Kit, when available, (don╒t even ask) will include:  complete project
files for MetroWerks CodeWarrior C++;  precompiled headers including
tons of inlines;  and examples, including complete, buildable code for at
least one plugin of each type.

PatchDance Technology (Programmers)
Some source code is available free for non-commercial use.
 - A number of PowerPlant compatible control classes were developed for
    the program.  Source code is freely available, just e-mail Tech Support.
    Many are highly specialized and reflect PatchDance╒s no-compromise,
    performance-first design (and may require some effort to adapt.)  They
    are supplied as-is, are poorly supported, and sometimes not too well
    documented.
 - Requests for other source code/methods will be considered.  We try to
    always support non-competing and academic efforts, but we must also
    protect our technology.  Functions relating to the database engine,
    imaging system, and many modeling operations (especially on spline
    surfaces) are usually confidential.  If anything looks interesting, ask.